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Abstract—Although communications-based cognitive engines 
have been proposed, very few have been implemented in a 
full system, especially in a space communications system. In 
this paper, we detail the implementation of a multi-objective 
reinforcement-learning algorithm and deep artificial neural net- 
works for the use as a radio-resource-allocation controller. The 
modular software architecture presented encourages re-use and 
easy modification for trying different algorithms. Various trade 
studies involved with the system implementation and integration 
are discussed. These include the choice of software libraries 
that provide platform flexibility and promote reusability, choices 
regarding the deployment of this cognitive engine within a 
system architecture using the DVB-S2 standard and commercial 
hardware, and constraints placed on the cognitive engine caused 
by real-world radio constraints. The implemented radio-resource- 
allocation-management controller was then integrated with the 
larger space-ground system developed by NASA Glenn Research 
Center (GRC). 

Keywords—cognitive engine; neural networks; reinforce- 
ment learning; SCaN Testbed; space communications; ma- 


chine learning 


I. INTRODUCTION 


With the continual increased computing performance with 
each new generation of general purpose processors (GPPs) 
and field programmable gate arrays (FPGAs), the usage of 
software-defined radios (SDRs) has become increasingly fea- 
sible to use in real space systems. As a result, proposed 
advanced algorithms for communications, such as cognitive 
algorithms, can now be deployed and tested. 

Onboard the International Space Station (ISS), NASA cur- 
rently has three operational SDRs on the Space Communi- 
cations and Navigation (SCaN) Testbed. NASA is interested 
in determining the applicability of SDRs for their future 
missions by considering their flexibility in changing signaling 
waveforms, new software development paradigms, and new 
operational aspects. We plan to use one of the SDRs on-orbit 
along with ground SDRs and commercial modems as part of 
a system to test the performance of a newly proposed multi- 
objective reinforcement learning algorithm using deep neural 


networks for the use as a radio-resource-allocation controller 
[1]. 

Currently, the state-of-the-art for NASA’s space communi- 
cations is adaptive communications, which works based on 
a lookup-table built by “experts” a priori. The table tells 
the radio which modulation-coding pair (“modcod”) to use 
based on the measured E,No (energy per symbol to noise 
power spectral density ratio). This table is built to maintain 
a quasi-error-free transmission [2]. In essence, this adaptive 
algorithm is a radio-resource-allocation optimization that takes 
into account bit error rate (BER) and throughput. Our proposed 
reinforcement-learning neural network (RLNN) cognitive en- 
gine [1] is to be a generalization of the adaptive algorithm’s 
bi-objective optimization to a multi-objective optimization. In 
our proposed case, the objectives that the cognitive algorithm 
tries to optimize are bit error rate (BER), throughput, occupied 
bandwidth, spectral efficiency, transmit power efficiency, and 
DC power consumption. The different parameters that can 
be changed in our experiment (thanks to the flexibility of 
an SDR waveform) is the modulation and coding scheme 
(modcod), roll-off factor, symbol rate, and additional transmit 
power. Instead of creating a static table that maps E,No values 
with transmission parameters (referred to as “action tuplets” 
throughout this paper), the cognitive engine learns the optimal 
actions given the channel condition through a reinforcement- 
learning process [1]. 

The goal of our experiment is to reuse the same system 
architecture as [2], but replace their adaptive algorithms work- 
station with our proposed multi-objective cognitive engine 
workstation. This significantly reduces development time, de- 
creases project risk, and provides a fairer comparison between 
the adaptive and cognitive algorithms. As a result, our im- 
plementation of the multi-objective cognitive engine will also 
be constrained to fit within the Digital Video Broadcasting— 
Satellite-Second Generation (DVB-S2) standard [3] as did 
the adaptive experiment in [2]. The DVB-S2 standard is 
commonly used in the commercial satellite broadcast market 
because of its granulairty of operational modes achieved via 


several modcod pairs that allow scalable data rates when 
using variable coding modulation (VCM) and adaptive coding 
modulation (ACM). 

This paper elaborates on the implementation details of 
porting the MATLAB algorithms in [1] to a real system. 
Section II discusses the cognitive applications to NASA’s 
missions. Section III summarizes the structure of our cognitive 
engine. Section IV discusses the software libraries used in 
this implementation and justifications for their use. Section V 
discusses implementation trade studies and adaptations of the 
original proposed cognitive engine to meet the constraints im- 
posed by the existing testing architecture. Section VI provides 
the implemented architecture to be used for ground and on- 
orbit testing. Finally, Section VII provides future work and 
conclusions based on the work presented in this paper. 


II. COGNITIVE APPLICATIONS TO NASAS MISSIONS 


NASAs future space architecture will enable human, 
robotic, and science exploration of the solar system. The rise in 
science data volume requirements, greater inter-connectivity, 
autonomous navigation, and the use of small satellites (among 
other requirements) will all add greater complexity to the 
communications network. Cognitive algorithms offer potential 
solutions to improve the efficiency and reduce the complex- 
ity of the future communications systems by managing and 
operating the system without human operators. This approach 
enables more system automation, but must also preserve the 
high level of reliability that space missions have achieved. 

The use of cognition in space communications is relatively 
new. Research underway at NASAs Glenn Research Center is 
looking at various aspects for cognitive applications [4]. The 
first domain is between the radios of the science spacecraft 
and either the ground station (for direct to ground connection) 
or through a relay satellite to the gateway ground station (or 
to a relay if on-board processed). The radios may optimize 
the link between the two radio nodes striving to optimize the 
pass (e.g. limit power consumption) or maximize the data 
throughput. Cognition could be applied to trade operating 
parameters (e.g., modulation, coding, frequency, power, and 
bandwidth) with performance parameters (e.g., bit/frame error 
rate, spectral efficiency, and power consumption). Effects on 
the links might include range changes, scintillation and other 
propagation effects, multipath, and interference. Cognitive 
algorithms could learn system behavior and change the con- 
figuration to optimize the links from different locations and 
conditions. 

The second application of cognitive algorithms might apply 
to the inter-connectivity and data flow from and among the 
science spacecraft, relay satellite, or ground station. As data 
is relayed or communicated through the network, cognition 
could update routing tables, move data through the network 
using a store and forward protocol, transferring data custody 
from node to node and optimally route data from science craft 
back to mission operations centers through various paths. 

Finally, higher level applications may benefit from cognition 
such as scheduling or configuration. For example, automating 
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Fig. 1. General flow block diagram of the RLNN (adapted from [1]) 


the scheduling of network assets among various space users 
based on past use or patterns of use in an effort to optimize 
the use of the network and maximize the time each user has 
access to the system. The network might also change the initial 
link configuration for a scheduled connection based on past 
performance or identify anomalous asset performance through 
a big data analysis. In addition, functions that the user space- 
craft could perform for itself might include orbit propagation 
to automate its antenna pointing, data storage monitoring to 
automate its request for services, and performance monitoring 
to report out of range telemetry or report quality of service 
assessments to the network manager. 

For each of these areas—radio-to-radio optimization, as- 
sured data connectivity or internetworking, and system level 
applications—cognition may offer potential benefits to reduce 
complexity or improve operations. In addition, multi-objective 
cognition will work across each of these domains and globally 
optimize system behavior and performance and further provide 
overall benefit to NASA missions. 


III. OVERVIEW OF COGNITIVE ENGINE 


The RLNN cognitive engine presented in [1] (an expan- 
sion on [5]) consists of a reinforcement-learning framework 
captured through the use of neural networks (NNs) to choose 
actions for both exploration and exploitation. An overview of 
the process flow of the RLNN is shown in Fig. 1. The explo- 
ration NN ensemble takes in an action tuple and the current 
E,No and predicts the normalized multi-objective weighted- 
sum performance value. After predicting the performance for 
every permutation of actions, one can then threshold the 
actions that resulted in “good” and “bad” performances. Most 
of the time, the reinforcement learner will choose to explore an 
action tuple in the “good” performance space. This is referred 
to as virtual exploration [1], [6]. 

The set of exploitation NN ensembles takes in the nor- 
malized multi-objective performance metric values and the 
current E,No and outputs the action parameter that should 
achieve the input objective performances. The exploitation NN 
ensembles hold the knowledge of the Q-table in traditional Q- 
learning. The exploitation NN ensembles are used to provide 
the action tuple that will give the best performance given 
the actions/performances the RLNN has already seen and the 
current E,No value. 

The measured performances for each of the objectives in 
the multi-objective function (bit error rate, throughput, occu- 


pied bandwidth, spectral efficiency, transmit power efficiency, 
and DC power consumption) are recorded. Periodically, the 
exploration and exploitation NNs are re-trained (using the 
Levenberg—Marquardt backpropagation algorithm) with the 
most recent action/performance knowledge. 


IV. SOFTWARE LIBRARIES 


The RLNN was written in the C++ language (we are 
using the C++11 standard [7]) with the intention of easily 
porting the engine between different machines and platforms 
(both ground-based radios and space-based radios). Unlike the 
authors’ original simulations [1] in MATLAB, C++ (being 
a lower-level language) does not come equipped with high 
level constructs, such as matrix algebra or NNs. In order to 
speed up development time, decrease development risk, and 
promote reuse, software libraries were leveraged for the matrix 
algebra operations, NN training and execution, and interfacing 
to external modems. 


A. Licensing 


There are a multitude of different open source software 
usage/redistribution licenses that an author can attribute to 
their work including (but not limited to) Berkeley Software 
Distribution (BSD) [8], GNU General Public License (GPL) 
[9], and GNU Lesser General Public License (LGPL) [10]. 
The GPL license requires that a work that uses a GPL- 
licensed work be released under GPL if redistributed [9]. As 
the name suggests, the LGPL license is a little more relaxed: 
a proprietary work that links to a LGPL-licensed library only 
needs to release the source code of the linked LGPL-licensed 
work, but not the full proprietary work [10]. These two types 
of licenses are known as “copyleft” licenses. Unlike (L)GPL, 
the BSD license is a permissive license that allows the use and 
redistribution of a BSD-licensed work without the release of 
the source code (but still needs to maintain copyright notices). 
This allows any proprietary application to use a BSD license 
without having to release its source code [8]. 

For our application, we chose to limit our software libraries 
to those that use permissive licenses, such as BSD. As the 
nature of SDR waveforms on space radios can be restricted 
by the International Traffic in Arms Regulations (ITAR) and 
other export control laws, the authors wanted to ensure their 
software could be added to the STRS Repository [11] without 
violating any software library licenses when redistributed. 
Unfortunately, limiting ourselves to only BSD-licensed, C++ 
software severely limited the scope of the libraries that could 
be used for this cognitive engine. 


B. Neural Network Library 


As the field of machine learning continues to rapidly ex- 
pand, the number of software libraries continues to increase. 
Many of these libraries have application program interfaces 
(APIs) that use high level scripting languages (such as Python) 
to make it easy for the user to get started. Although some of 
these libraries were based on C/C++ cores (for performance), 
their C++ APIs were generally undocumented or nonexistent. 


For example, this was the case for the popular Torch library 
[12]. Another common issue was that some of the more 
popular libraries (such as Caffe [13]) that had C++ APIs also 
had a long list of dependencies and a complex build process. 
This issue would make it hard to port our cognitive engine to 
resource-constrained space radios. A third issue encountered 
was that some libraries (such as Darknet [14]) were designed 
to be used for very complex, deep convolutional NNs, which 
would be excessive for our cognitive engine. 

MLPack [15] was chosen to be used for the NN library. 
Although MLPack’s artificial neural network (ANN) is not 
as mature as other software libraries, it provided many ad- 
vantages. First, the build process was relatively simple and 
the required dependency list was short. Second, its API is 
well documented both with function definitions in Doxygen 
and code usage examples. Third, other machine learning 
algorithms in MLPack have been used by our cognitive com- 
munciations colleagues at NASA GRC, so using a common 
library would ease incorporation of our cognitive engine with 
their activities. For those interested in using MLPack’s ANN 
library, currently, the ANN support is not yet included in any 
stable release—it is only included in the master GIT branch 
[15]. Additionally, MLPack does not support the Levenberg— 
Marquardt backpropagation algorithm for training. The authors 
wrote their own implementation of the algorithm and verified 
its performance using MATLAB’s “trainlm” function in its 
Neural Network Toolbox. 


C. Matrix Library 


To handle the matrix and vector storage and operations, Ar- 
madillo [16], was chosen. Armadillo abstracts matrix algebra 
to an API similar to MATLAB, making it easier to port the 
algorithms in [1]. This library was chosen primarily because 
it was also used internally by MLPack making interfacing 
easier. Another useful feature is that it transparently handles 
multithreading for larger operations. 


D. External Input-Output 


The DVB-S2 receiver and the BPSK transmitter ground 
modems attached to our cognitive engine communicate using 
UDP. The Boost.Asio [17] library was leveraged to handle all 
UDP inputs and outputs for our cognitive engine. Boost is a 
very common and powerful C++ library and is also internally 
used by MLPack. To save and resume the state of the cognitive 
engine, the Boost.Serialization [18] library was used. This 
allows us to compare how the cognitive engine performs when 
using already trained weights on the next ground station pass 
versus having to relearn the weights at the beginning of a pass. 


V. TRADE STUDIES 


Porting theoretical algorithms in MATLAB to a real system 
brings many challenges. One of the goals of our experiments 
is to leverage as much existing waveforms and technology 
as possible. This lowers risk, lowers development time, and 
increases chances of near-term adoption. We chose to fit our 
algorithms within the DVB-S2 standard to reuse the already 


developed and extensively tested space transmitter waveform 
implemented by colleagues at NASA GRC [2]. Additionally, 
we chose to use the same test setup as used by [2], which uses 
commercial DVB-S2 receivers on the ground. These modems 
have physical limitations, such as how fast the automatic gain 
control (AGC) can handle transmit power changes and the rate 
at which frame error rate (FER) statistics are updated. The fol- 
lowing sections discuss how our implementation accomodates 
these challenges. 


A. Fitting within DVB-S2 Standard 


In [1], a transmit action tuple consists of five parameters: 
modulation scheme, code rate, roll-off factor, additional trans- 
mit power, and symbol rate. Each time the cognitive engine 
receives a new frame, it needs to record both the performance 
of the frame (in terms of the multi-objective fitness values) 
and the action tuple that was used on that frame. Although 
the DVB-S2 protocol includes the modcod and roll-off factor 
within the physical layer and baseband headers, respectively, 
the symbol rate and additional transmit power are not included 
in any of the headers. To generalize this cognitive engine 
to any set of action parameters, the action tuple had to be 
specified outside of the DVB-S2 headers. 

The round trip time (RTT) for the adaptive algorithm in 
[2] at 1M baud was measured to be approximately 40 ms. 
This time includes both constant and variable delays. Constant 
delays include the transmission time of an AOS frame on the 
ML605 transmitter, the propagation delay from the ground 
station to the ISS (assuming the changing range is negligible), 
the frame decoding time on the space-based receiver, and 
the propagation delay from the ISS to the ground. Variable 
delays include the processing time on the ground (assuming 
the algorithm runs on a CPU), the time it takes between when 
the new action is decoded on the space radio to when the 
next frame can be updated with the new parameters, and the 
amount of time it takes for a DVB-S2 frame to transmitted 
to the ground (higher symbol rates takes less time because 
the number of bits in a DVB-S2 frame is fixed). These delays 
make it more difficult to know on the ground which action 
tuple was used on each frame if we want to update the action 
tuple on a frame-by-frame basis. 

In addition to the variable timing delays, the dynamic nature 
of the wireless links causes another challenge. There is a 
(relatively high) chance that corrupted frames will be received 
on the ground when the cognitive engine makes “bad” action 
decisions before it is fully trained. For a simple solution in 
which a header is placed within the DVB-S2 payload with 
the action tuple used, the cognitive engine would never know 
the action tuples that caused poor performance. The uplink 
feedback channel could also get corrupted, which would cause 
the action tuple to not change on the next frame. This would 
cause a solution that relied solely on timing to record a 
received performance with the new action tuple, when in fact 
the action tuple from the previous frame was used again. 

In our case, the scheme is very simple and does not require 
an additional protocol header. Instead of updating on a frame- 


by-frame basis, our cognitive engine updates at a period equal 
to or greater than the longest round trip time—in the 1M baud 
case, this would be a 40-ms period. In that 40-ms period, 
we will receive multiple frames with that action tuple, but 
our RLNN only uses the latest sample with that action tuple. 
We can solely base our protocol on timing without the need 
for any headers—the ground system sends the new action 
tuple and then waits for the worst case RTT. It then records 
the performance of a frame after the RTT timer elapses and 
chooses a new action. This makes the assumption that the 
uplink channel will not corrupt the feedback AOS frame. This 
is a valid assumption because, in our case, the feedback link 
is a more robust link than the most robust DVB-S2 downlink 
parameters. As a result, if the uplink gets corrupted and the 
action tuple never gets changed, then it does not matter which 
action is recorded on the ground because every action is going 
to result in poor performance. 

For a cognitive engine that uses the knowledge of every 
frame received (regardless of whether or not it is the same 
action as the previous frame) a more complex timing architec- 
ture can be used. By leveraging the knowledge of the constant 
timing delays in the system, one can split the RTT time into 
periods of “certainty” and “uncertainty”. In this architecture, 
a header is included inside the DVB-S2 payload that contains 
the action tuple. Essentially, if a DVB-S2 frame is received 
during the period of “certainty”, the receiver already knows 
which action tuple was used for that frame (it does not even 
need to read the header inside of the payload). When a frame is 
received during the period of “uncertainty”, it is ambiguous to 
the receiver what action tuple was used, so it needs to read the 
header inside of the frame. If the downlink is corrupted, then 
any frame that is received during the period of “certainty” can 
still be recorded (because the receiver is certain which action 
was taken without reading the frame). Any corrupted frame 
received during the period of “uncertainty” is just discarded 
and not recorded. It is guaranteed that, in every RTT, there is 
at least one frame in the window of “certainty”. Fig. 2 shows 
a summary of how this timing architecture works. 

Finally, the DVB-S2 standard is a constant-symbol-rate 
protocol. It does not handle variable symbol rates as the 
simulation in [1], so, in our testing, we will not be varying 
the symbol rate. The testing will only change the modcod, 
additional transmit power, and roll-off factor “on-the-fly”. 


B. Hardware Limitations 


An implicit assumption used in the simulation in [1] is 
that the extra transmit power can be changed on a frame-by- 
frame basis. It is true that the space transmitter can change the 
additional transmit power on a frame-by-frame basis, but this 
would result in poor performance at the receiver because the 
AGC would not be able to keep up with the fast fluctuating 
power. As a result, a patch will be used for the implemented 
RLNN that limits the magnitude of the change in additional 
transmit power from one action tuple to another. 

Another hardware limitation is that the modem’s calculated 
frame error rate is only updated at 1 Hz. As a result, many 
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Fig. 2. Timing architecture showing the period of “certainty” and period of “uncertainty” for a RTT of 40 ms (1M baud symbol rate). The rectangles with 
“4”, “6”, and “8” represent the received 16-APSK, 8-PSK, and QPSK frames, respectively. 


consecutive action tuples will all be given the same frame 
error rate. Alternatively, we could use the E,No measurements 
reported by the modem (at 100 Hz) and estimate by the FER 
by using the FER-E,No curves (measured a priori) for the 
received action tuple’s modcod. We plan to characterize and 
compare both of these approaches. 


VI. IMPLEMENTED ARCHITECTURE 


The implemented RLNN cognitive engine was written in 
object-oriented C++ using the libraries discussed in Section IV 
and trade study results in Section V. The RLNN is made up of 
an RLNN core, which is where the cognitive algorithms reside, 
and external drivers, which communicate with the ground 
modems. The object architecture for this implementation is 
shown in Fig. 3. The following sections provide details on 
each of these objects. 


A. RLNN Core 


The RLNN core is comprised of three modules: a training 
buffer, the NN predictors, and an application-specific object. 
The RLNN core provides the “glue” code between these 
modules. The RLNN core is designed to be a standalone object 
regardless of the physical interfaces. It has two main purposes: 
choose an action tuple based on exploration and exploitation 
and record the action tuple’s corresponding performance. 

1) Training Buffer: The training buffer is the main database 
holding the training samples for the explore and exploit 
NNs. The buffer holds the latest N unique actions and their 
corresponding performances. When training needs to occur, 
the user provides the training buffer with the fields needed for 
the input and output labels and any normalization parameters 
for both the explore and exploit NNs. The buffer then outputs 
the formatted input and output training samples to be directly 


used with the NN Predictor modules. The training buffer is 
constructed using Armadillo vector and matrix structures. 

2) NN Predictor: The NN Predictor module abstracts ML- 
Pack’s ANN architecture to a simple interface similar to 
MATLAB’s Neural Network Toolbox. Each NN predictor 
module instantiates an ensemble of parallel NNs to be used 
for either exploration or exploitation prediction. When the 
“predict” class method is called, each of the parallel NNs 
compute a prediction and then the mean prediction is outputted 
back to the user. 

We use two types of NN Predictor modules: a trainer 
module and an execution module. The trainer module is used 
whenever the NNs need to be retrained. Upon retraining, the 
weights are copied to the execution module, which is used for 
online predictions. This decoupling allows the training to occur 
simultaneously in a separate thread while the RLNN continues 
normal execution. This is important because NN training can 
take on the order of many seconds to complete, so we cannot 
block the main execution until the training is complete. For the 
exploration prediction, there is a single training module and a 
single execution module. For the exploitation prediction, we 
use a vector of trainer-module and execution-module pairs. 
Each trainer-module and execution-module pair corresponds 
to the prediction of one of the action parameters in an 
action tuple. It is important to note that, within each of these 
trainer/execution modules, there are multiple NNs running in 
parallel. The number of NNs that need to be run in parallel 
is a trade-off between the accuracy of the predicted action, 
the number of threads that can be executed in parallel, and 
training time, while maintaining real-time execution. 

3) Application Specific Object: The RLNN core “glue” 
code, training buffer, and NN predictor modules were designed 
to be completely generic, so that the RLNN could be reused 
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Fig. 3. Implemented software architecture of the RLNN. 


easily. The application-specific object provides the “context” 
for our particular experiment. This object processes the raw 
measurements from the modems, calculates the normalized 
multi-objective performances, and helps the RLNN algorithms 
maintain generality. For those interested in reusing our cog- 
nitive engine for a different application (or different multi- 
objective performance metrics), only the Application Specific 
Object needs to swapped with a new object containing the 
new parameters and functions. For our experiment, this object 
is also where any hardware constraint patches are applied— 
estimating the FER from the FER-E,No curves and limiting 
the magnitude between jumps of additional transmit power. 


B. External Drivers 


The external drivers communicate with the external 
modems. In the on-orbit experiments, the ViaSat modem is 
used for gathering E,No/FER statistics and the ML605 modem 
is used to transmit the new action tuplets to the space- 
based DVB-S2 transmitter [2]. For ground testing, GRC has 
ported the DVB-S2 waveform to their Advanced Space Radio 
Platform (ASRP) instead of having to use the JPL radio 
breadboard or ground integration unit. 

1) ViaSat Modem Driver: The ViaSat modem sends its 
E;No/RSSI statistics over a UDP/IP/Ethernet stack, while the 
FER statistics need to be polled using the simple network 
management protocol (SNMP). This driver parses incoming 
E,No/RSSI packets from the Boost.ASIO UDP receiver and 
SNMPGet application [19] and returns them for usage within 
the RLNN core. 

2) ML605 Modem Driver: The ML605 modem driver 
packetizes the chosen action tuple into a UDP/IP/Ethernet 
frame it requires for embedding into the AOS frame. We 
use Boost.ASIO’s library to send raw Ethernet frames to the 
ML605 because it does not support the full IP stack. 

3) ASRP Modem Driver: The ASRP modem driver converts 
the chosen action tuple into the format required for sending 
remote procedure calls (RPC) to the ASRP web server. We 
use the UNIX “curl” [20] command to build and send these 
RPC messages. 


C. Logging 

Logging of important information on each iteration (action 
tuple chosen, performance measured, exploitaiton/exploration, 
timestamps, etc.) are written into a global text file using 
a name/value pair. Logging is controlled using preprocessor 
directives. The log file is easily parsed by name using a script 
in MATLAB. 

The Boost.Serialization library is used to archive and load 
the state of the objects in the RLNN. The user has the 
option to resume a session or start a new session and whether 
or not to save that session upon exit. For each object, the 
Boost.Serialization library writes its properties to a human- 
readable text file. When the RLNN is instantiated, the proper- 
ties are initialized with the values saved in the archive files. 


VII. CONCLUSION 


In this paper, the implementation of the algorithms de- 
scribed in [1] has been presented. The software libraries 
utilized, the modifications for real-world constraints, and the 
object-oriented software architecture were discussed. At the 
time of writing, this implemented system is currently in the 
ground-testing stage and will be used for on-orbit experiments 
in May 2017. The goal of this paper was to provide the reader 
with insight into building cognitive engines and integrating 
them into a real system. Upon export review, it is planned that 
the RLNN core code will be released to the public. Additional 
future work includes including a real-time received power 
predictor into the RLNN based on channel models [21], [22]. 
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